Walkthrough

Detects OCI Sigstore bundles via a new Client.HasBundles call and branches verification into bundle-format (OCI referrer) or legacy paths; adds bundle-aware attestation parsing and protobuf bundle referrer creation, extends OCI client interface and tests, and updates acceptance BDD for bundle-format attestations.

Changes

Bundle Format Attestation Support

Sequence Diagram

sequenceDiagram
    participant CLI as CLI
    participant Eval as Evaluator
    participant OCI as OCI Client
    participant Verifier as Sigstore Verifier
    participant Parser as Attestation Parser

    CLI->>Eval: ValidateImage(ctx, image)
    Eval->>OCI: HasBundles(ctx, imageRef)
    alt Bundles present
        OCI-->>Eval: true
        Eval->>Verifier: VerifyImageAttestations (NewBundleFormat=true)
        Verifier->>OCI: Fetch referrers / bundles
        OCI-->>Verifier: bundles/referrers
        Verifier->>Parser: attestationResult(attestations, useBundles=true)
        Parser->>Parser: Parse DSSE envelope(s), validate payloadType
        Parser-->>Verifier: provenance/attestation entries
        Verifier-->>Eval: verification result
    else No bundles or detection error
        OCI-->>Eval: false / error
        Eval->>Verifier: VerifyImageSignatures (legacy)
        Verifier->>OCI: Fetch tag-based signatures
        OCI-->>Verifier: signatures
        Verifier->>Parser: attestationResult(signatures, useBundles=false)
        Parser->>Parser: ProvenanceFromSignature
        Parser-->>Verifier: provenance/attestation entries
        Verifier-->>Eval: verification result
    end
    Eval-->>CLI: final result

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

❌ Failed checks (1 warning)

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• Add HasBundles() method to oci.Client interface for testable bundle detection
• Auto-detect Sigstore bundles in verify_attestation and verify_image Rego builtins
  - Uses bundle verification path with NewBundleFormat=true when bundles present
  - Falls back to legacy path when no bundles found or detection fails
  - Skips non-in-toto payload types silently
• Refactor ApplicationSnapshotImage.hasBundles() to use new Client.HasBundles() method
• Add comprehensive unit tests covering bundle and legacy verification paths
• Add acceptance test scenario for bundle-format attestation verification

Add HasBundles method to Client interface

internal/utils/oci/client.go

Implement HasBundles in FakeClient mock

internal/utils/oci/fake/client.go

Refactor hasBundles to use Client interface

internal/evaluation_target/application_snapshot_image/application_snapshot_image.go

Description

When bundles are detected, sigstoreVerifyImage() calls VerifyImageAttestations() with
IntotoSubjectClaimVerifier and returns those results as image signatures. This can allow
ec.sigstore.verify_image to succeed even if there are no image signatures, as long as attestations
exist.

Code

internal/rego/sigstore/sigstore.go[R135-152]

+	client := ecoci.NewClient(ctx)
+	useBundles, err := client.HasBundles(ctx, ref)
+	if err != nil {
+		logger.WithField("error", err).Debug("bundle detection failed, falling back to legacy path")
+		useBundles = false
+	}
+
+	var signatures []oci.Signature
+	if useBundles {
+		logger.Debug("bundles detected, using bundle verification path")
+		checkOpts.NewBundleFormat = true
+		checkOpts.ClaimVerifier = cosign.IntotoSubjectClaimVerifier
+		signatures, _, err = client.VerifyImageAttestations(ref, checkOpts)
+	} else {
+		checkOpts.ClaimVerifier = cosign.SimpleClaimVerifier
+		logger.Debug("verifying image signatures")
+		signatures, _, err = client.VerifyImageSignatures(ref, checkOpts)
+	}

Evidence

The builtin named/declared as verifying an image signature switches to attestation verification on
the bundle path. Repo acceptance code also treats signature referrers and attestation referrers as
distinct artifact types, reinforcing that VerifyImageAttestations is not the same thing as verifying
image signatures.

internal/rego/sigstore/sigstore.go[89-110]
internal/rego/sigstore/sigstore.go[135-152]
acceptance/image/image.go[407-415]
acceptance/image/image.go[702-711]
acceptance/examples/sigstore.rego[23-56]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ec.sigstore.verify_image` is intended to verify *image signatures*, but when `HasBundles` is true it verifies *attestations* instead (`VerifyImageAttestations`) and returns those as `signatures`.

### Issue Context
The acceptance helpers create distinct referrers for signatures vs attestations (different artifact types). Switching `verify_image` to verify attestations changes the security meaning of policies that rely on `verify_image` to assert an image was signed.

### Fix Focus Areas
- internal/rego/sigstore/sigstore.go[135-152]

### Suggested fix
- In the `useBundles` branch of `sigstoreVerifyImage`, keep `checkOpts.NewBundleFormat = true` but call `VerifyImageSignatures(ref, checkOpts)` (not `VerifyImageAttestations`).
- Keep `checkOpts.ClaimVerifier = cosign.SimpleClaimVerifier` for image signatures (the attestation-specific verifier should remain in `verify_attestation`).
- Update/extend unit tests so the bundle path asserts `VerifyImageSignatures` is used, and ensure the acceptance scenario still passes with referrer signatures present.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In bundle mode, attestationResult() silently drops entries when Payload() fails or when the payload
is not valid DSSE JSON, rather than returning an error term for the user. This makes malformed
bundle data harder to diagnose because the builtin may report success with empty attestations/errors
until downstream policy checks fail generically.

Code

internal/rego/sigstore/sigstore.go[R384-400]

+		if useBundles {
+			payload, pErr := s.Payload()
+			if pErr != nil {
+				log.WithField("error", pErr).Debug("skipping bundle entry: cannot read payload")
+				continue
+			}
+			var dsseEnvelope struct {
+				PayloadType string `json:"payloadType"`
+			}
+			if jErr := json.Unmarshal(payload, &dsseEnvelope); jErr != nil {
+				log.WithField("error", jErr).Debug("skipping bundle entry: not a valid DSSE envelope")
+				continue
+			}
+			if dsseEnvelope.PayloadType != "application/vnd.in-toto+json" {
+				log.WithField("payloadType", dsseEnvelope.PayloadType).Debug("skipping bundle entry with non-in-toto payloadType")
+				continue
+			}

Evidence

The bundle path uses continue on payload read failure and JSON unmarshal failure; legacy parsing
paths add "parsing attestation" errors to the output, so this is a regression in surfaced detail for
certain malformed inputs.

internal/rego/sigstore/sigstore.go[372-409]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`attestationResult(..., useBundles=true, ...)` currently skips malformed bundle entries (payload read / invalid JSON) without recording anything in `errors`, which reduces debuggability.

### Issue Context
Skipping non-in-toto payload types is fine (explicit requirement), but unreadable payloads or invalid DSSE envelope JSON are unexpected and should be surfaced in the builtin output similarly to other parsing errors.

### Fix Focus Areas
- internal/rego/sigstore/sigstore.go[384-400]

### Suggested fix
- When `s.Payload()` fails: append an error term like `"parsing attestation: cannot read payload: ..."` instead of `continue`.
- When DSSE envelope JSON unmarshal fails: append an error term like `"parsing attestation: not a valid DSSE envelope: ..."` instead of `continue`.
- Keep the existing behavior to silently skip non-in-toto `payloadType` entries.
- Add a unit test for the invalid-JSON DSSE envelope case to lock in the improved error reporting.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.